home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-06-07 | 51.5 KB | 1,624 lines |
-
-
- Draft Interfaces Group Evolution May 1993
-
-
-
-
-
- Evolution of the Interfaces Group of MIB-II
-
- 1 June 1993
-
-
- Keith McCloghrie
- Hughes LAN Systems
- kzm@hls.com
-
- Frank J. Kastenholz
- FTP Software
- kasten@ftp.com
-
-
-
- Status of this Memo
-
- This document is an Internet Draft. Internet Drafts are
- working documents of the Internet Engineering Task Force
- (IETF), its Areas, and its Working Groups. Note that other
- groups may also distribute working documents as Internet
- Drafts.
-
- Internet Drafts are valid for a maximum of six months and may
- be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet Drafts as reference
- material or to cite them other than as a "work in progress".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 1]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- 1. Introduction
-
- MIB-II [3] is the core set of managed objects defined for use
- by network management of the Internet suite of protocols.
- MIB-II was defined using the SNMPv1 Network Management
- Framework.
-
- This memo discusses the 'interfaces' group of MIB-II,
- especially the experience gained from the definition of
- numerous media-specific MIB modules for use in conjunction
- with the 'interfaces' group for managing various sub-layers
- beneath the internetwork-layer. It proposes clarifications
- to, and extensions of, the architectural issues within the
- current model used for the 'interfaces' group.
-
- This memo also includes a MIB module. As well as including
- new experimental MIB definitions to support the architectural
- extensions, this MIB module also re-specifies the 'interfaces'
- group of MIB-II in a manner which is both compliant to the
- SNMPv2 SMI and semantically-identical to the existing SNMPv1-
- based definitions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 2]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- 2. The SNMPv2 Network Management Framework
-
- The SNMPv2 Network Management Framework consists of four major
- components. They are:
-
- o RFC 1441 which defines the SMI, the mechanisms used for
- describing and naming objects for the purpose of
- management.
-
- o RFC 1213 defines MIB-II, the core set of managed objects
- for the Internet suite of protocols.
-
- o RFC 1445 which defines the administrative and other
- architectural aspects of the framework.
-
- o RFC 1448 which defines the protocol used for network
- access to managed objects.
-
- The Framework permits new objects to be defined for the
- purpose of experimentation and evaluation.
-
-
- 2.1. Object Definitions
-
- Managed objects are accessed via a virtual information store,
- termed the Management Information Base or MIB. Objects in the
- MIB are defined using the subset of Abstract Syntax Notation
- One (ASN.1) defined in the SMI. In particular, each object
- object type is named by an OBJECT IDENTIFIER, an
- administratively assigned name. The object type together with
- an object instance serves to uniquely identify a specific
- instantiation of the object. For human convenience, we often
- use a textual string, termed the descriptor, to refer to the
- object type.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 3]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- 3. Experience with the Interfaces Group
-
- One of the strengths of internetwork-layer protocols such as
- IP [6] is that they are designed to run over any network
- interface. In achieving this, IP considers any and all
- protocols it runs over as a single "network interface" layer.
- A similar view is be taken by other internetwork-layer
- protocols. This concept is represented in MIB-II by the
- 'interfaces' group which defines a generic set of managed
- objects such that any network interface can be managed in an
- interface-independent manner through these managed objects.
- The 'interfaces' group provides the means for additional
- managed objects specific to particular types of network
- interface (e.g., a specific medium such as Ethernet) to be
- defined as extensions to the 'interfaces' group for media-
- specific management. Since the standardization of MIB-II,
- many such media-specific MIB modules have been defined.
-
- Experience in defining these media-specific MIB modules has
- shown that the model defined by MIB-II is too simplistic
- and/or static for some types of media-specific management. As
- a result, some of these media-specific MIB modules have
- assumed an evolution/loosening of the model. This memo is a
- proposal to document/standardize the evolution of the model
- and to fill in the gaps caused by that evolution.
-
-
- 3.1. Areas of Clarification/Revision
-
- There are four areas for which experience indicates that
- clarification or revision of the model would be helpful. The
- next sections discuss these.
-
-
- 3.1.1. Interface Numbering
-
- MIB-II defines an object, ifNumber, whose value represents:
-
- "The number of network interfaces (regardless of their
- current state) present on this system."
-
- Each interface is identified by a unique value of the ifIndex
- object, and the description of ifIndex constrains its value as
- follows:
-
-
-
-
-
-
- Expires November 1993 [Page 4]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- "Its value ranges between 1 and the value of ifNumber.
- The value for each interface must remain constant at
- least from one re-initialization of the entity's network
- management system to the next re-initialization."
-
- This constancy requirement on the value of ifIndex for a
- particular interface is vital for efficient management.
- However, an increasing number of devices allow for the dynamic
- addition/removal of network interfaces. One example of this
- is a dynamic ability to configure the use of SLIP/PPP over a
- character-oriented port. For such dynamic additions/removals,
- the combination of the constancy requirement and the
- restriction that the value of ifIndex is less than ifNumber is
- problematic.
-
-
- 3.1.2. Interface Sub-Layers
-
- Experience in defining media-specific management information
- has shown the need to distinguish between the multiple sub-
- layers beneath the internetwork-layer. In addition, there is
- a need to manage these sub-layers in devices (e.g., MAC-layer
- bridges) which are unaware of which, if any, internetwork
- protocols run over these sub-layers. As such, a model of
- having a single conceptual row in the interfaces table (MIB-
- II's ifTable) represent a whole interface underneath the
- internetwork-layer, and having a single associated media-
- specific MIB module (referenced by the ifSpecific object) is
- too simplistic. A further problem arises with the value of
- the ifType object which has enumerated values for each type of
- interface.
-
- Consider, for example, an interface with PPP running over an
- HDLC link which uses a RS232-like connector. Each of these
- sub-layers has its own media-specific MIB module. If all of
- this is represented by a single conceptual row in the ifTable,
- then an enumerated value for ifType is needed for that
- specific combination, and that row's ifSpecific variable can
- "point" to only one of the three media-specific MIB modules.
- Furthermore, even if there was a convention for deciding which
- MIB module is referenced by ifSpecific then there is still a
- lack of a method to describe the relationship of all the sub-
- layers of the MIB stack.
-
- An associated problem is that of upward and downward
-
-
-
-
-
- Expires November 1993 [Page 5]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- multiplexing of the sub-layers. An example of upward
- multiplexing is MLP (Multi-Link) which provides load-sharing
- over several serial lines by appearing as a single point-to-
- point link to the sub-layer(s) above. An example of downward
- multiplexing would be several instances of PPP, each running
- over a Frame Relay virtual circuit, all of which run over the
- same ISDN B channel. The current MIB structure does not allow
- for these sorts of relationships to be described.
-
-
- 3.1.3. Virtual Circuits
-
- Several of the sub-layers for which media-specific MIB modules
- have been defined are connection oriented (e.g., Frame Relay,
- X.25). Experience has shown that each effort to define such a
- MIB module revisits the question of whether separate
- conceptual rows in the ifTable are needed for each virtual
- circuit. Most, if not all, of these efforts to date have
- decided to have all virtual circuits reference a single
- conceptual row in the ifTable.
-
-
- 3.1.4. Bit and Character Oriented Interfaces
-
- RS-232 is an example of a character-oriented sub-layer over
- which (e.g., through use of PPP) IP datagrams can be sent.
- Due to the packet-based nature of many of the objects in the
- ifTable, experience has shown that it is not appropriate to
- have a character-oriented sub-layer represented by a (whole)
- conceptual row in the ifTable.
-
- Experience has also shown that it is sometimes desirable to
- have some management information for bit-oriented interfaces,
- which are similarly difficult to represent by a (whole)
- conceptual row in the ifTable. For example, to manage the
- channels of a DS1 circuit, where only some of the channels are
- carrying packet-based data.
-
-
- 3.2. Clarifications/Revisions
-
- The following clarifications and/or revisions are proposed.
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 6]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- 3.2.1. Interface Numbering
-
- One solution to the interface numbering problem would be to
- redefine ifNumber to be the largest value of ifIndex, but the
- utility of such an object is questionable, and such a re-
- definition would require ifNumber to be deprecated. Thus, an
- improvement would be to deprecate ifNumber and not replace it.
- However, the deprecation of ifNumber would require a change to
- that portion of ifIndex's definition which refers to ifNumber.
- So, since the definition of ifIndex must be changed anyway in
- order to solve the problem, changes to ifNumber do not benefit
- the solution.
-
- The solution adopted in this memo is just to delete the
- requirement that the value of ifIndex must be less than the
- value of ifNumber, and to retain ifNumber with its current
- definition. It could be argued that this is a change in the
- semantics of ifIndex; however, all existing implementations
- conform to this new definition, and in the interests of not
- requiring changes in existing implementations and in the many
- existing media-specific MIBs, it is proposed that this change
- does not require ifIndex to be deprecated.
-
- This solution also results in the possibility of "holes" in
- the ifTable, i.e., the ifIndex values of conceptual rows in
- the ifTable are not necessarily contiguous, but SNMP's GetNext
- (and SNMPv2's GetBulk) operation easily deals with such holes.
- The value of ifNumber still represents the number of
- conceptual rows, which increases/decreases as new interfaces
- are dynamically added/removed. The vital constancy
- requirement is met by requiring that after an interface is
- dynamically removed, its ifIndex value is not re-used (by
- another dynamically added interface) until after the following
- re-initialization of the network management system. This
- avoids the need for a priori assignment of ifIndex values for
- all possible interfaces which might be added dynamically.
-
- Because of the restriction of the value of ifIndex to be less
- than ifNumber, interfaces have been numbered with small
- integer values. This has led to the ability by humans to use
- the ifIndex values as (somewhat) user-friendly names for
- network interfaces (e.g., "interface number 3"). With the
- relaxation of the restriction on the value of ifIndex, there
- is now the possibility that ifIndex values could be assigned
- as very large numbers (e.g., memory addresses). Such numbers
-
-
-
-
-
- Expires November 1993 [Page 7]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- would be much less user-friendly. Therefore, this memo
- recommends that ifIndex values still be assigned as small
- integer values starting at 1, even though the values in use at
- any one time are not necessarily contiguous. (Note that this
- makes it easy for agents which dynamically add new interfaces,
- to remember which values have been assigned.)
-
-
- 3.2.2. Interface Sub-Layers
-
- One possible but not recommended solution to the problem of
- representing multiple sub-layers would be to retain the
- concept of one conceptual row for all the sub-layers of an
- interface and have each media-specific MIB module identify its
- "superior" and "subordinate" sub-layers through OBJECT
- IDENTIFIER "pointers". The drawbacks of this scheme are: 1)
- that the superior/subordinate pointers are contained in the
- media-specific MIB modules, and thus, a manager could not
- learn the structure of an interface, without inspecting
- multiple pointers in different MIB modules; this is overly
- complex and only possible if the manager has knowledge of all
- the relevant media-specific MIB modules; 2) current MIB
- modules would all need to be retrofitted with these new
- "pointers"; 3) this scheme does not adequately address the
- problem of upward and downward multiplexing; and 4) enumerated
- values of ifType are needed for each combination of sub-
- layers.
-
- Another possible but not recommended scheme would be to retain
- the concept of one conceptual row for all the sub-layers of an
- interface and have a new separate MIB table to identify the
- "superior" and "subordinate" sub-layers and to contain OBJECT
- IDENTIFIER "pointers" to media-specific MIBs. Effectively,
- one conceptual row in the ifTable would represent each
- combination of sub-layers between the internetwork-layer and
- the wire. While this scheme has fewer drawbacks, it would
- deprecate the use of ifSpecific and it still does not support
- downward multiplexing, such as PPP over MLP: since MLP makes
- two (or more) serial lines appear to the layers above as a
- single physical interface, PPP over MLP should appear to the
- internetwork-layer as a single interface; this scheme,
- however, would result in two (or more) conceptual rows in the
- ifTable, both of which the internetwork-layer would run over.
- This scheme also requires enumerated values of ifType for each
- combination of sub-layers.
-
-
-
-
-
- Expires November 1993 [Page 8]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- The solution adopted in this memo is to have an individual
- conceptual row in the ifTable to represent each sub-layer, and
- have a new separate MIB table (the ifStackTable, see section 4
- of this memo) to identify the "superior" and "subordinate"
- sub-layers through INTEGER "pointers" to the appropriate
- conceptual rows in the ifTable. This solution supports both
- upward and downward multiplexing, allows the ifSpecific
- pointer in each conceptual row of the ifTable to point to the
- media-specific MIB module for that sub-layer, such that the
- new table need only be referenced to obtain information about
- layering, and it only requires enumerated values of ifType for
- each sub-layer, not for combinations of them. However, it
- does require that the descriptions of some objects in the
- ifTable (specifically, ifType, ifPhysAddress, ifInUcastPkts,
- and ifOutUcastPkts) be generalized so as to apply to any sub-
- layer (rather than only to a sub-layer immediately beneath the
- network layer, as at present), plus some (specifically,
- ifSpeed) which need to have appropriate values identified for
- use when a generalized definition does not apply to a
- particular sub-layer.
-
- In addition, this adopted solution makes no requirement that a
- device, in which a sub-layer is instrumented by a conceptual
- row of the ifTable, be aware of whether an internetwork
- protocol runs on top of (i.e., at some layer above) that sub-
- layer.
-
-
- 3.2.3. Virtual Circuits
-
- This memo recommends that, in general, connection-oriented
- sub-layers do not have a conceptual row in the ifTable for
- each virtual circuit. This avoids the proliferation of
- conceptual rows, especially those which have considerable
- redundant information. (Note, as a comparison, that
- connection-less sub-layers do not have conceptual rows for
- each remote address.) There may, however, be circumstances
- under which it is appropriate for a virtual circuit of a
- connection-oriented sub-layer to have its own conceptual row
- in the ifTable; an example of this might be PPP over a Frame
- Relay virtual circuit. The MIB in section 4 of this memo
- supports such circumstances.
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 9]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- 3.2.4. Bit and Character Oriented Interfaces
-
- About half the objects in the ifTable are applicable to every
- type of interface: packet-oriented, character-oriented, and
- bit-oriented. Of the other half, two are applicable to both
- character-oriented and packet-oriented interfaces, and the
- rest are applicable only to packet-oriented interfaces. Thus,
- while it is desirable for consistency to be able to represent
- any/all types of interfaces in the ifTable, it is not possible
- to implement the full ifTable for bit- and character-oriented
- sub-layers.
-
- One possible but not recommended solution to this problem
- would be to split the ifTable into two (or more) new MIB
- tables, one of which would contain objects that are relevant
- only to packet-oriented interfaces (e.g. PPP), and another
- that may be used by all interfaces. This is highly
- undesirable since it would require changes in every agent
- implementing the ifTable (i.e., just about every existing SNMP
- agent).
-
- The solution adopted in this memo builds upon the fact that
- compliance statements in SNMPv2 (in contrast to SNMPv1) refer
- to object groups, where object groups are explicitly defined
- by listing the objects they contain. Thus, in SNMPv2,
- multiple compliance statements can be specified, one for all
- interfaces and additional ones for specific types of
- interfaces. The separate compliance statements can be based
- on separate object groups, where the object group for all
- interfaces can contain only those objects from the ifTable
- which are appropriate for every type of interfaces. Using
- this solution, every sub-layer can have its own conceptual row
- in the ifTable.
-
- Thus, the following section contains definitions of the
- objects of the existing 'interfaces' group of MIB-II, in a
- manner which is both SNMPv2-compliant and semantically-
- equivalent to the existing MIB-II definitions. With
- equivalent semantics, and with the BER ("on the wire")
- encodings unchanged, these definitions retain the same OBJECT
- IDENTIFIER values as assigned by MIB-II. Thus, no rewrite of
- existing agents is required.
-
- Three new object groups are defined: the ifGeneralGroup
- containing those objects applicable to all types of network
-
-
-
-
-
- Expires November 1993 [Page 10]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- interfaces; the ifCharacterGroup containing those objects
- applicable to character-oriented (but not packet-oriented)
- network interfaces; and the ifPacketGroup containing those
- objects applicable only to packet-oriented network interfaces.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 11]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- 4. Definitions
-
- IF-MIB DEFINITIONS ::= BEGIN
-
- IMPORTS
- MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32,
- Integer32, TimeTicks, experimental FROM SNMPv2-SMI
- DisplayString, PhysAddress, RowStatus FROM SNMPv2-TC
- MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
- mib-2, interfaces FROM RFC-1213;
-
-
- -- combining the experimental parts of this MIB with the
- -- existing ifExtensions MIB (RFC 1229) should be considered.
- -- ifExtensions is defined in RFC 1239 as { mib-2 12 }
-
- ifMIB MODULE-IDENTITY
- LAST-UPDATED "9305262355Z"
- ORGANIZATION "IETF Interfaces MIB Working Group"
- CONTACT-INFO
- " Keith McCloghrie
- Hughes LAN Systems
- 1225 Charleston Road
- Mountain View, Ca. 94043
-
- Tel: 415-966-7934
- Fax: 415-966-7980
- E-mail: kzm@hls.com."
- DESCRIPTION
- "The MIB module to describe generic objects for
- network interface sub-layers. This MIB is an
- updated version of MIB-II's ifTable."
- ::= { experimental xx }
-
- ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 12]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- -- the Interfaces group
-
- ifNumber OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of network interfaces (regardless of
- their current state) present on this system."
- ::= { interfaces 1 }
-
-
- -- the Interfaces table
-
- -- The Interfaces table contains information on the entity's
- -- interfaces. Each sub-layer below the internetwork-layer
- -- of a network interface is considered to be an interface.
-
- ifTable OBJECT-TYPE
- SYNTAX SEQUENCE OF IfEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "A list of interface entries. The number of
- entries is given by the value of ifNumber."
- ::= { interfaces 2 }
-
- ifEntry OBJECT-TYPE
- SYNTAX IfEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry containing management information
- applicable to a particular interface."
- INDEX { ifIndex }
- ::= { ifTable 1 }
-
- IfEntry ::=
- SEQUENCE {
- ifIndex Integer32,
- ifDescr DisplayString,
- ifType INTEGER,
- ifMtu Integer32,
- ifSpeed Gauge32,
- ifPhysAddress PhysAddress,
-
-
-
-
-
- Expires November 1993 [Page 13]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- ifAdminStatus INTEGER,
- ifOperStatus INTEGER,
- ifLastChange TimeTicks,
- ifInOctets Counter32,
- ifInUcastPkts Counter32,
- ifInNUcastPkts Counter32,
- ifInDiscards Counter32,
- ifInErrors Counter32,
- ifInUnknownProtos Counter32,
- ifOutOctets Counter32,
- ifOutUcastPkts Counter32,
- ifOutNUcastPkts Counter32,
- ifOutDiscards Counter32,
- ifOutErrors Counter32,
- ifOutQLen Gauge32,
- ifSpecific OBJECT IDENTIFIER
- }
-
- ifIndex OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "A unique value, greater than zero, for each
- interface. It is recommended that values are
- assigned contiguously starting from 1. The value
- for each interface sub-layer must remain constant
- at least from one re-initialization of the
- entity's network management system to the next
- re-initialization."
- ::= { ifEntry 1 }
-
- ifDescr OBJECT-TYPE
- SYNTAX DisplayString (SIZE (0..255))
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "A textual string containing information about the
- interface. This string should include the name of
- the manufacturer, the product name and the version
- of the hardware interface."
- ::= { ifEntry 2 }
-
- ifType OBJECT-TYPE
- SYNTAX INTEGER {
-
-
-
-
-
- Expires November 1993 [Page 14]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- other(1), -- none of the following
- regular1822(2),
- hdh1822(3),
- ddn-x25(4),
- rfc877-x25(5),
- ethernet-csmacd(6),
- iso88023-csmacd(7),
- iso88024-tokenBus(8),
- iso88025-tokenRing(9),
- iso88026-man(10),
- starLan(11),
- proteon-10Mbit(12),
- proteon-80Mbit(13),
- hyperchannel(14),
- fddi(15),
- lapb(16),
- sdlc(17),
- ds1(18), -- T-1
- e1(19), -- european equiv. of T-1
- basicISDN(20),
- primaryISDN(21), -- proprietary serial
- propPointToPointSerial(22),
- ppp(23),
- softwareLoopback(24),
- eon(25), -- CLNP over IP [11]
- ethernet-3Mbit(26),
- nsip(27), -- XNS over IP
- slip(28), -- generic SLIP
- ultra(29), -- ULTRA technologies
- ds3(30), -- T-3
- sip(31), -- SMDS
- frame-relay(32)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The type of interface."
- ::= { ifEntry 3 }
-
- ifMtu OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The size of the largest datagram which can be
-
-
-
-
-
- Expires November 1993 [Page 15]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- sent/received on the interface, specified in
- octets. For interfaces that are used for
- transmitting network datagrams, this is the size
- of the largest network datagram that can be sent
- on the interface."
- ::= { ifEntry 4 }
-
- ifSpeed OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "An estimate of the interface's current bandwidth
- in bits per second. For interfaces which do not
- vary in bandwidth or for those where no accurate
- estimation can be made, this object should contain
- the nominal bandwidth. For a sub-layer which has
- no concept of bandwidth, this object should be
- zero."
- ::= { ifEntry 5 }
-
- ifPhysAddress OBJECT-TYPE
- SYNTAX PhysAddress
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The interface's address at its protocol sub-
- layer. For interfaces which do not have such an
- address (e.g., a serial line), this object should
- contain an octet string of zero length."
- ::= { ifEntry 6 }
-
- ifAdminStatus OBJECT-TYPE
- SYNTAX INTEGER {
- up(1), -- ready to pass packets
- down(2),
- testing(3) -- in some test mode
- }
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "The desired state of the interface. The
- testing(3) state indicates that no operational
- packets can be passed."
- ::= { ifEntry 7 }
-
-
-
-
-
- Expires November 1993 [Page 16]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- ifOperStatus OBJECT-TYPE
- SYNTAX INTEGER {
- up(1), -- ready to pass packets
- down(2),
- testing(3) -- in some test mode
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The current operational state of the interface.
- The testing(3) state indicates that no operational
- packets can be passed."
- ::= { ifEntry 8 }
-
- ifLastChange OBJECT-TYPE
- SYNTAX TimeTicks
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime at the time the interface
- entered its current operational state. If the
- current state was entered prior to the last re-
- initialization of the local network management
- subsystem, then this object contains a zero
- value."
- ::= { ifEntry 9 }
-
- ifInOctets OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of octets received on the
- interface, including framing characters."
- ::= { ifEntry 10 }
-
- ifInUcastPkts OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of packets, delivered by this sub-
- layer to a higher-layer protocol, which were not
- addressed to a multicast or broadcast address at
- this sub-layer."
-
-
-
-
-
- Expires November 1993 [Page 17]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- ::= { ifEntry 11 }
-
- ifInNUcastPkts OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of packets, delivered by this sub-
- layer to a higher-layer protocol, which were
- addressed to a multicast or broadcast address at
- this sub-layer."
- ::= { ifEntry 12 }
-
- ifInDiscards OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of inbound packets which were chosen
- to be discarded even though no errors had been
- detected to prevent their being deliverable to a
- higher-layer protocol. One possible reason for
- discarding such a packet could be to free up
- buffer space."
- ::= { ifEntry 13 }
-
- ifInErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of inbound packets that contained
- errors preventing them from being deliverable to a
- higher-layer protocol."
- ::= { ifEntry 14 }
-
- ifInUnknownProtos OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of packets received via the interface
- which were discarded because of an unknown or
- unsupported protocol."
- ::= { ifEntry 15 }
-
-
-
-
-
- Expires November 1993 [Page 18]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- ifOutOctets OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of octets transmitted out of the
- interface, including framing characters."
- ::= { ifEntry 16 }
-
- ifOutUcastPkts OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of packets that higher-level
- protocols requested be transmitted, and which were
- not addressed to a multicast or broadcast address
- at this sub-layer, including those that were
- discarded or not sent."
- ::= { ifEntry 17 }
-
- ifOutNUcastPkts OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of packets that higher-level
- protocols requested be transmitted, and which were
- addressed to a multicast or broadcast address at
- this sub-layer, including those that were
- discarded or not sent."
- ::= { ifEntry 18 }
-
- ifOutDiscards OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of outbound packets which were chosen
- to be discarded even though no errors had been
- detected to prevent their being transmitted. One
- possible reason for discarding such a packet could
- be to free up buffer space."
- ::= { ifEntry 19 }
-
-
-
-
-
-
- Expires November 1993 [Page 19]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- ifOutErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of outbound packets that could not be
- transmitted because of errors."
- ::= { ifEntry 20 }
-
- ifOutQLen OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The length of the output packet queue (in
- packets)."
- ::= { ifEntry 21 }
-
- ifSpecific OBJECT-TYPE
- SYNTAX OBJECT IDENTIFIER
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "A reference to MIB definitions specific to the
- particular media being used to realize the
- interface. For example, if the interface is
- realized by an ethernet, then the value of this
- object refers to a document defining objects
- specific to ethernet. If this information is not
- present, its value should be set to the OBJECT
- IDENTIFIER { 0 0 }, which is a syntactically valid
- object identifier, and any conformant
- implementation of ASN.1 and BER must be able to
- generate and recognize this value."
- ::= { ifEntry 22 }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 20]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- --
- -- The Interface Stack Group
- --
- -- Implementation of this group is mandatory for all systems
-
- ifStackTable OBJECT-TYPE
- SYNTAX SEQUENCE OF IfStackEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The table containing information on the
- relationships between the multiple sub-layers of
- network interfaces. In particular, it contains
- information on which sub-layers run 'on top of'
- which other sub-layers. Each sub-layer
- corresponds to a conceptual row in the ifTable."
- ::= { ifMIBObjects 1 }
-
-
- ifStackEntry OBJECT-TYPE
- SYNTAX IfStackEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Information on a particular relationship between
- two sub-layers, specifying that one sub-layer runs
- on 'top' of the other sub-layer. Each sub-layer
- corresponds to a conceptual row in the ifTable."
- INDEX { ifStackHigherLayer, ifStackLowerLayer }
- ::= { ifStackTable 1 }
-
-
- IfStackEntry ::=
- SEQUENCE {
- ifStackHigherLayer Integer32,
- ifStackLowerLayer Integer32,
- ifStackStatus RowStatus
- }
-
-
- ifStackHigherLayer OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
-
-
-
-
-
- Expires November 1993 [Page 21]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- "The value of ifIndex corresponding to the higher
- sub-layer of the relationship, i.e., the sub-layer
- which runs on 'top' of the sub-layer identified by
- the corresponding instance of ifStackLowerLayer.
- If there is no higher sub-layer (below the
- internetwork layer), then this object has the
- value 0."
- ::= { ifStackEntry 1 }
-
-
- ifStackLowerLayer OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The value of ifIndex corresponding to the lower
- sub-layer of the relationship, i.e., the sub-layer
- which runs 'below' the sub-layer identified by the
- corresponding instance of ifStackHigherLayer. If
- there is no lower sub-layer, then this object has
- the value 0."
- ::= { ifStackEntry 2 }
-
-
- ifStackStatus OBJECT-TYPE
- SYNTAX RowStatus
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "The status of the relationship between two sub-
- layers.
-
- Changing the value of this object from "active" to
- "notInService" or "destroy" will likely have
- consequences up and down the interface stack.
- Thus, write access to this object is likely to be
- inappropriate for some types of interfaces, and
- many implementations will choose not to support
- write-access for any type of interface."
- ::= { ifStackEntry 3 }
-
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 22]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- -- conformance information
-
- ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 }
-
- ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 }
- ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 }
-
-
- -- compliance statements
-
- ifCompliance MODULE-COMPLIANCE
- STATUS current
- DESCRIPTION
- "The compliance statement for SNMPv2 entities
- which have network interfaces."
-
- MODULE -- this module
- MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup }
-
- GROUP ifCharacterGroup
- DESCRIPTION
- "This group is mandatory only for those network
- interfaces which are character-oriented or
- packet-oriented."
-
- GROUP ifPacketGroup
- DESCRIPTION
- "This group is mandatory only for those network
- interfaces which are packet-oriented."
-
- OBJECT ifStackStatus
- SYNTAX INTEGER { active(1) } -- subset of RowStatus
- MIN-ACCESS read-only
- DESCRIPTION
- "Write access is not required, and only one of the
- six enumerated values for the RowStatus textual
- convention need be supported, specifically:
- active(1)."
- ::= { ifCompliances 1 }
-
-
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 23]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- -- units of conformance
-
- ifGeneralGroup OBJECT-GROUP
- OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress,
- ifAdminStatus, ifOperStatus, ifLastChange,
- ifSpecific }
- STATUS current
- DESCRIPTION
- "A collection of objects providing information
- applicable to all network interfaces."
- ::= { ifGroups 1 }
-
- ifCharacterGroup OBJECT-GROUP
- OBJECTS { ifInOctets, ifOutOctets }
- STATUS current
- DESCRIPTION
- "A collection of objects providing information
- specific to packet-oriented or character-oriented
- network interfaces."
- ::= { ifGroups 2 }
-
- ifPacketGroup OBJECT-GROUP
- OBJECTS { ifMtu, ifInUcastPkts, ifInNUcastPkts,
- ifInDiscards, ifInErrors, ifInUnknownProtos,
- ifOutUcastPkts, ifOutNUcastPkts, ifOutDiscards,
- ifOutErrors, ifOutQLen }
- STATUS current
- DESCRIPTION
- "A collection of objects providing information
- specific to packet-oriented network interfaces."
- ::= { ifGroups 3 }
-
- ifStackGroup OBJECT-GROUP
- OBJECTS { ifStackStatus }
- STATUS current
- DESCRIPTION
- "A collection of objects providing information on
- the layering of MIB-II interfaces."
- ::= { ifGroups 4 }
-
- END
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 24]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- 5. Acknowledgements
-
- The proposals in this memo are the result of conversations and
- discussions with many people, including at least the
- following: Fred Baker, Ted Brunner, Chuck Davin, Jeremy
- Greene, Marshall Rose, Kaj Tesink, and Dean Throop. However,
- it does not necessarily represent any consensus among the
- above-mentioned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 25]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- 6. References
-
- [1] M.T. Rose and K. McCloghrie, Structure and Identification
- of Management Information for TCP/IP-based internets,
- Request for Comments 1155. (May, 1990).
-
-
- [2] M. Rose and K. McCloghrie, Editors, Concise MIB
- Definitions, RFC 1212, March 1991.
-
-
- [3] K. McCloghrie and M.T. Rose, Management Information Base
- for Network Management of TCP/IP-based internets - MIB-2,
- Request for Comments 1213. (March, 1991).
-
-
- [4] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
- Simple Network Management Protocol, Request for Comments
- 1157. (May, 1990).
-
-
- [5] International Organization for Standardization,
- Information processing systems - Open Systems
- Interconnection - Specification of Abstract Syntax
- Notation One (ASN.1), International Standard 8824,
- (December, 1987).
-
-
- [6] J. Postel, Internet Protocol, RFC791, September 1981.
-
-
- [7] K. McCloghrie, Extensions to the Generic-Interface MIB,
- RFC1229, May 1991.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 26]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- 7. Security Considerations
-
- Security issues are not discussed in this memo.
-
-
- 8. Authors' Address
-
- Keith McCloghrie
- Hughes LAN Systems
- 1225 Charleston Rd,
- Mountain View, Ca 94043
- 415-966-7934
- kzm@hls.com
-
- Frank Kastenholz
- FTP Software
- 2 High Street
- North Andover, Mass. USA 01845
- (508)685-4000
- kasten@ftp.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 27]
-
-
-
-
- Draft Interfaces Group Evolution May 1993
-
-
- Table of Contents
-
-
- 1 Introduction .......................................... 2
- 2 The SNMPv2 Network Management Framework ............... 3
- 2.1 Object Definitions .................................. 3
- 3 Experience with the Interfaces Group .................. 4
- 3.1 Areas of Clarification/Revision ..................... 4
- 3.1.1 Interface Numbering ............................... 4
- 3.1.2 Interface Sub-Layers .............................. 5
- 3.1.3 Virtual Circuits .................................. 6
- 3.1.4 Bit and Character Oriented Interfaces ............. 6
- 3.2 Clarifications/Revisions ............................ 6
- 3.2.1 Interface Numbering ............................... 7
- 3.2.2 Interface Sub-Layers .............................. 8
- 3.2.3 Virtual Circuits .................................. 9
- 3.2.4 Bit and Character Oriented Interfaces ............. 10
- 4 Definitions ........................................... 12
- 5 Acknowledgements ...................................... 25
- 6 References ............................................ 26
- 7 Security Considerations ............................... 27
- 8 Authors' Address ...................................... 27
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires November 1993 [Page 28]
-
-